城商行自建异地应用级灾备中心，选址、技术选型、带宽三大难题怎么办？ | 最佳实践
以下内容来自社区探讨，欢迎点击阅读原文到社区与同行交流本话题
城商行计划重建异地应用级灾备承载10多个交易类应用系统，有一些疑问请教？
背景：我们中小型地方性城市商业银行需要自建应用级异地灾备中心，承载10余个重要交易类应用系统，数据量约有30T。我们现在顾虑就是怕异地灾备演练时，数据回写的时间过长，造成数据不一致或演练时间过长不好把控。所以特发一些探讨的话题，希望借助同行的经验，给与一些参考。不吝指教！ 问题1：自建异地灾备中心应如何选址？ 问题2：采用什么技术性价比比较高？ 问题3：数据需要回写的话，带宽应该怎么考虑？ 希望大家给与一些建议和经验，感谢！ （问题来自@saltyp 某银行系统架构师）
@lding1985 银行软件开发工程师：
异地灾备建设主要需要满足两个方面需求：一是监管要求，两地三中心建的不完善，监管一般是会找麻烦的，年年检查都是事。
二是自身需求，满足业务连续性的要求，这个需要自己评估，依次顺序是明确业务范围、明确要建哪些系统、数据复制技术、主机平台及技术等。
问题1：选址问题，一定要满足监管要求，多和监管单位沟通，目前监管貌似新增要求灾备机房所在地必须要有分支机构。
问题2：性价比最高的一定是使用备份恢复技术，找备份厂商做，通过备份设备去复制数据。存储便宜，而且带宽需求低，缺点是RPO时间长，真出了问题切换丢的数据多。
问题3：带宽需要集合你的峰值写数据量、数据复制技术来看，不同的技术、RPO的要求时间不同，对带宽的需求自然不一样。实时同步最高，备份方式每天同步一次最低。
@bbaimm88 自贡银行 系统架构师：
你这个问题涉及太多了，相当于建应用级机房了（首要是梳理系统间访问关系，切过去日终跑批依赖不能有遗漏）。
1、中小银行选址跨地市100KM以上吧。
2、性价比不好论，得结合你的生产应用程序是X86平台还是AIX平台，AIX平台就贵了。既然是应用平台，又要考虑节约，就用x86 与Power虚拟化来实现。应用代码不需要从主中心实时复制过去，直接版本手动更新。只有数据库需要实时复制到异地。那么网络你采用两套链路物理分开（一套专用数据库复制链路；一条应用链路回写主中心）。 是x86平台的虚拟化就很好解决了，使用备份系统传输 去重很高，效率好（比如nbu），ESXI主机用多盘位 解决（低成本）。 网络架构可以简化些便于管理。
3、数据需要回写，需要结合重要系统数据库日增量、周增量、与月增量，来做评估。且多家运营商。如果有互联网业务，还得考虑公网接入。
最后你们数据中心上 DNS 没有，上应用交互没有（比如F5），有的话，就依托F5来调度。就好管控了。
题主 saltyp： 我们交易类系统拟采用X86平台，但核心还是想利用Power小机，然后存储用DS8K系列，有啥好定制化的建议吗？ bbaimm88 回复 saltyp： VMware 虚拟化加Power VM ，并且要把虚拟化高可用建设好，减少维护难度难度。异地人员值守维护要跟上。不然真正切换管控能力跟不上。虚拟化减少成本，成熟度也很高了。
@ggffss 某银行 安全工程师：
1、异地灾备一定要监管沟通，一般要求200KM，具体要看监管要求，灾备自建的话，电力供应需要双路供电，要设置发电机，实现比较困难，租用IDC机房来做会比较容易实现。
2、运营商现在一般都不支持跨城市的裸光纤租用，如果只是做数据级的灾备，根据数据的备份量申请两条专线就行了，现在城商行一般都是做同城双活，异地数据备份。
3、如果做应用双活，可以考虑使用VXLAN技术，使异地灾备中心的服务器与本地的服务器同一个网段，使用F5做调度。
@zihan524524 某银行：
你这10多个交易系统30TB数据应该是分配容量，实际容量可能没这么多，根据我们的经验，中小城商行OLTP类数据库数据基本在500G以下，如果大多数都超过500G，就要考虑数据清理、数据归档策略了，数据量越大，维护成本越高。言归正传，针对你提的这几个问题，谈下自己的看法，供探讨。
1、自建异地灾备中心如何选址？
选址问题，每个行的实际情况都不一样，根据实际情况进行选择。灾难备份中心的选址应服从国家战略安全要求，并综合考虑生产中心与灾难备份中心交通和电讯的便利性与多样性，以及灾难备份中心当地的业务与技术支持能力、电讯资源、地理地质环境、公共资源与服务配套能力等外部支持条件，在选择自建方式时应综合考虑投资效益、运营管理成本、运营管理队伍的稳定性和应急能力等因素。
具体的你可以参考两个规范文件：信息安全技术 信息系统灾难恢复规范》和《银行业信息系统灾难恢复管理规范》。
2、采用什么技术性价比比较高？
你问的是使用什么复制技术吧？应根据实际环境因地制宜选择灾备复制技术。
一般来说，一套应用系统，容灾需考虑以下方面：
（1）应用程序
如果应用程序部署在虚拟机上，采用虚拟机容灾方案。
如果应用程序部署在物理机上，最好能进行虚拟化迁移，然后使用虚拟机容灾方案；无法迁移的，容灾需要在异地重新搭建新环境，并根据实际情况使用存储复制或者rsync等工具保持应用版本同步。
（2）数据库
数据是非常重要的，可以选择数据库复制技术或存储复制技术，也可以两者结合，建议以数据库技术为主。不管是数据库复制还是存储复制，建议采用三点闭环复制方案，这样三点中任意一点出现故障，都能保证RPO满足要求，且三点之间可以任意切换。
（3）硬件负载或专用设备
需要在异地重新容灾负载和专用设备。
（4）网络环境
需要在异地灾备重新部署，建议分支机构拉两条专线，一条到主中心，一条到异地灾备中心。
3、数据需要回写的话，带宽应该怎么考虑？
灾备切换演练一般分为两种，一种是真实切换，对外营业一段时间后回切至主中心；另一种只是在异地做内部验证，验证完成后，马上恢复主中心业务。
针对第二种灾备切换演练，内部做完验证后，异地灾备数据一般不用回切，可以直接丢弃，不存在回写。
针对第一种，对外营业一段时间后回切至主中心，数据是需要进行回写的，一般数据复制都是增量进行的，且交易数据变化量往往较小，再加上是计划内切换演练，数据回写时间可控，另外在演练期间，可以提前临时增加些带宽，以应对突发流量需求。
带宽问题，是个值得探讨的问题，异地灾备复制靠长距离的网络进行数据传输，长距离的网络带宽低、时延大，对于复制数据量大的中小银行来说，需要较高的带宽来满足异地灾备数据复制，这样必然会带来网络线路成本的上升，再加上复制带宽是动态变化的，复制所需的网络带宽可能随时出现大量增长，
因此，异地复制网络带宽需要采取“开源节流”措施，降低带宽成本，提高网络线路利用率。可以采取必要措施，在网络带宽成本可控的情况下，合理利用带宽资源，提高带宽使用率。
（1）加强异地复制网络流量的监控，定期进行复制流量分析。
网络线路上，可以采用网络回溯分析系统对异地复制线路进行实时监控；
针对存储复制和数据库复制，可以编写脚本收集数据进行观测；
针对虚拟机复制，在被复制的虚拟机上部署Nmon脚本，编写自动化工具进行分析；
通过以上三个层面的分析，可以掌握异地灾备复制流量使用情况，并根据使用情况作出一些优化。
（2）裁剪不必要异步数据复制流量
针对虚拟机复制，可以考虑将一些本地备份数据、上下游系统卸载数据，统一集中放置的NAS服务器上。
（3）开启数据压缩功能，提高异步复制带宽
开启数据压缩功能，如存储复制，可以考虑在SAN ROUTER上开启数据压缩功能，数据压缩比例基本可以达到2:1到4:1，即100Mbps可以跑出200Mbps-400Mbps的效果，对于数据库层面的复制，例如ORACLE ADG，也可以开启压缩功能，提高带宽利用率。
（4）增加带宽
如果通过实施以上1、2、3的措施带宽使用率依然较高，可以适当增加带宽。
@leodong 银行系统工程师：
数据库：1、运维维护简单，风险小数据库系统可以使用异地存储复制，RPO时间会长一些，回写的时间也会长一些，但是演练的数据变化量应该不会太大。2、数据库也可以使用逻辑复制，只复制数据库日志，数据量小，同步时间断。
应用：1、应用程序和日志全部通过存储复制，同步完成后，拉起存储资源，变更配置，启动应用程序，平时不需要投产，切换时间长2、如果应用程序无需数据日志传输同步，可以直接投产变更生产与异地一起投产变更。异地应用可以直接启动应用程序。参与日常投产，切换时间短。
@匿名用户 某银行：
要建立应用级异地灾备中心，个人感觉首先考虑必要性，其次考虑投入能否接受，毕竟城市商业银行是区域性银行，如果真要发生异常，需要用到启用了异地数据中心，那灾难级别已经达到了一定程度，异地数据中心能否真正起到作用，起到多大作用，都得进行考量。毕竟建立一个异地应用级灾备中心的投入不是一个小数目。
至于技术方面，建议使用基于TCP网络的数据增量同步软件，减少同步的数据量。
题主 saltyp： 我们也觉得没必要，现有的异地就是数据级，演练采用拉快照的方式进行，但上层一定要做成应用级，所以我们也很无奈呀。 melody2004： 异地应用级双活模式，我的想法是通过入口流量调度的方式，按客户源IP将较小比例的流量分配至异地灾备中心，达到应用级双活的目的。由于应用服务器存在写日志的需要，在设计应用层双活时，仍需考虑日志数据库同步问题。同时，异地情况下传输距离较远，数据库无法满足双活要求，因此异地数据中心只能承载较小流量的业务数据。 分库分表也是一种解决的办法，用户分属不同的数据中心，数据实时同步要求不高。 seagl： 每个支行都要部署异地跨区域的长途专线么？如果没有，这种应用级灾备也是虚假的。那就在原来数据级的基础上，搭建应用服务器进行验证、演练、应急使用。也算是一种准应用级异地灾备。 melody2004： 分支机构异地灾备通讯线路推荐考虑4G VPDN，节省通讯链路费用，稳定性也能满足。
@melody2004 某城市商业银行 系统架构师：
我认为异地选址问题主要考虑两个方面：
第一、距离和自然灾害防范问题。 银监办发﹝2010﹞114号《中国银行业监督管理委员会办公厅关于印发<商业银行数据中心监管指引>的通知》中第三条指出 “灾备中心异地模式是指灾备中心与生产中心处于不同地理区域，一般距离在数百公里以上，不会同时面临同类区域性灾难风险，如地震、台风和洪水等。 ”。
第二、灾备机房选址中的周边环境问题。主要考虑电力供应、发电机布放、附近是否存在水患、空调外机扰民等情况。如果是专业数据中心园区就不存在这些问题了。
题主 saltyp：
请教一下您，数百公里以上，应该是指200公里以上就行了对吗？ melody2004 回复 saltyp： 一般是300公里，最好跟当地监管沟通一下，毕竟异地灾备是监管评分中的一项内容。 hbu2001 回复 saltyp： 200KM是对的。
@dkstrike 某城商行 系统工程师：
异地灾备选址，监管要求大于等于800km，异地我们这边做的数据级的，用的30m的线路，会做一些数据级的备份，如果你要双活，建议使用裸光纤，DWDM，GPFS等
@hbu2001 金融行业事业部 系统运维工程师 ：
看你们的技术水平与硬件环境与预算，图省事就用存储复制，图省带宽就用数据日志复制，图省钱就用异构环境。
题主 saltyp：
请教一下您，异构环境是怎么实现呀？两边完全独立的环境吗？那数据怎么同步呢？ hbu2001 回复 saltyp： 异构环境必须用数据同步软件来实现，比如你生产用AIX+ORACLE，灾备用LINUX+ORACLE，同步软件用ORACLE DG来实现或者第三方的CDC来同步，如果用存储同步就不能使用异构环境。
@guangshi007 技术经理：
切换时间与你的架构，配置密切相关，选址的话主要考虑的是距离，供电条件，裸光纤还是VPN，应用允许的网络抖动是多长时间，系统建设目标是数据灾备，应用灾备，存储灾备………等等都有关系，数据库是用DG，还是gg，还是其它手段同步数据？？这些都得根据目标，预算，现有条件等等综合考虑～～～
欢迎点击文末阅读原文到社区讨论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
金融企业如何科学进行备份系统选型及设计，减少后期运维故障
http://www.talkwithtrend.com/Article/245437
某银行生产和灾备 Power 云化实践
http://www.talkwithtrend.com/Article/243919
某银行跨数据中心的数据库双活及灾备建设经验分享
http://www.talkwithtrend.com/Document/detail/tid/40225
欢迎关注社区 “灾备”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/3457
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场